Driving device

ABSTRACT

A driving device  5  includes: a fault detection device  11  that determines a fault in an actuator  6 ; a serial interface  7  that communicates with an MCU  2 ; a memory device  10  that stores a program received from the MCU  2  and a fault determination result by the fault detection device  11 ; a CPU  9  that causes the fault detection device  11  to execute the fault determination according to a fault determination request from the MCU  2 ; a timer device  16  that measures a limit time over which fault determination is performed and a determination period of fault determination; and a counter device  17  that counts the number of repeats of fault determination and the number of fault occurrences in the actuator  6.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a driving device, and more particularlyto a driving device that drives actuators installed in a vehicle such asan automobile.

2. Description of the Related Art

Important initiatives have been undertaken in recent years tostandardize the functional safety of electrical equipment and electronicdevices installed in automobiles. Rigorous assessment in terms ofdefining faults in mounted electronic components, clarifying faultdetermination criteria, and addressing the faults applies also toelectronic control units (ECUs) that control power trains. The demandsplaced also on responsiveness to such faults are likewise stringent.

As system complexity increases, the targets of fault determinationbecome more numerous, and fault determination requirements becomelikewise more complex. The processing load of the ECU and thecommunication traffic between the ECU and associated devices increase asa result.

Herein, the term “power train” denotes an apparatus for efficientlytransmitting rotational energy, generated by an engine, to tires. Thepower train includes a clutch, a transmission, a propeller shaft, adifferential gear and a drive shaft.

A system control device disclosed in Japanese Patent ApplicationPublication No. H7-43257 is made up of two chips, namely a host-sideunit and a sub-side unit. The host-side unit has a host processor thatperforms main system control. The sub-side unit has a subprocessor thatperforms subsidiary system control, and a standby system processor thatperforms system control occasionally when an abnormality occurs. Thehost processor and the subprocessor operate according to a first clock,and the standby system processor operates according to a second clock.The host processor, the subprocessor and the standby system processoreach have a fault self-determination execution circuit. The faultself-determination execution circuits of the host processor and of thesubprocessor perform fault determination using the second clock, whilethe fault self-determination execution circuit of the standby systemprocessor performs fault determination using the first clock. JapanesePatent Application Publication No. H7-43257 discloses the feature ofsecuring a reliable fail-safe function by using different clock systemin the standby system processor alone.

A vehicular electronic control device disclosed in Japanese PatentApplication Publication No. 2014-046730 is provided with a driver IC anda microcontroller. The microcontroller inputs a diagnosis start signalto the driver IC, via serial communication. Upon reception of thediagnosis start signal, the driver IC reads, from a ROM, the ON/OFFstate of each driver circuit, in a group of registers. Each driverdiagnosis circuit performs then diagnosis upon turn-on/off, according tothe values of the registers. Drive circuits detected to be faulty as aresult of the diagnosis are brought to an inactive state, and themicrocontroller is notified of the fact.

The load drive device disclosed in Japanese Patent ApplicationPublication No. 2009-077542 is built into an electronic control device.The load drive device drives a load such as a solenoid. The load drivedevice is provided with a drive circuit and a diagnosis circuit. Thediagnosis circuit diagnoses the state of the load. The diagnosis circuitoperates upon system initialization or while the drive circuit isstopped. The drive circuit stops when a drive-stop signal is inputted tothe electronic control device, from a control circuit that controls thedrive circuit. The normal operation of the diagnosis circuit is thuschecked in a state where the load drive device remains built into theelectronic control device.

SUMMARY OF THE INVENTION Technical Problem

In the system control device disclosed in Japanese Patent ApplicationPublication No, H7-43257, each unit is equipped with a faultself-determination execution circuit, and the host-side unit is notifiedof the fault detection results using hard logic. Therefore this was forinstance problematic in that, without changes in hardware, softwarecould not cope with various fault detection conditions.

The vehicular electronic control device disclosed in Japanese PatentApplication Publication No. 2014-046730 envisages only turn-on/off ofeach driver circuit stored in a ROM. In Japanese Patent ApplicationPublication No. 2014-046730, the ROM can hold only a diagnosis pattern(on/off combination) of identical timing (simultaneous) for each drivercircuit. This was therefore problematic in that separate faultdetermination scenarios for each driver circuit could not be programmed.

The diagnosis circuit in the load drive circuit disclosed in JapanesePatent Application Publication No. 2009-077542 operates upon systeminitialization or while the drive circuit is stopped. Therefore,Japanese Patent Application Publication No. 2009-077542 was problematicin that, without changes in hardware, software could not cope withvarious fault detection conditions.

In order to solve the above problems, it is an object of the presentinvention to provide a driving device that is capable of meeting variousfault detection requirements for each actuator, in actuator faultdetection, using software and without changes in hardware.

Solution to Problem

The present invention is a driving device that is connected between acontrol unit and an actuator and that drives the actuator throughcontrol by the control unit, the driving device comprising: a faultdetection device that determines a fault in the actuator; a serialinterface that communicates with the control unit; a memory device thatstores a fault determination result by the fault detection device and aprogram received from the control unit via the serial interface; aprocessor that, according to a fault determination request from thecontrol unit, executes the program, and causes the fault detectiondevice to execute the fault determination; a timer that measures a limittime for fault determination by the fault detection device and adetermination period of fault determination by the fault detectiondevice; and a counter that counts the number of repeats of the faultdetermination executed by the fault detection device, and the number offault occurrences in the actuator as detected by the fault detectiondevice, wherein, upon reception of the fault determination request fromthe control unit, the processor executes the program to cause as aresult the fault detection device to execute the fault determination forthe number of repeats for each determination period within the limittime, and after the limit time has elapsed, transmits faultdetermination results by the fault detection device to the control unit.

Advantageous Effects of Invention

In the present invention, the driving device includes a memory deviceand a processor, and is configured to detect faults through softwareprocessing. Therefore, fault determination according to a desired faultdetermination requirement can be carried out simply through rewriting ofthe fault determination requirement in the memory device. It becomesaccordingly possible to meet various fault detection requirements inactuator fault detection, using software and without changes inhardware.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating the structure of a general powertrain ECU.

FIG. 2 is a time chart illustrating communication, during normaloperation, between an MCU and a driving device in a general power trainECU.

FIG. 3 is a time chart illustrating communication, upon faultoccurrence, between an MCU and a driving device in a general power trainECU.

FIG. 4 is a block diagram illustrating the structure of a driving deviceaccording to Embodiment 1 of the present invention.

FIG. 5 is a time chart, during normal operation, between an MCU and adriving device in Operation example 1 of the driving device according toEmbodiment 1 of the present invention.

FIG. 6 is a flowchart illustrating a process flow in Operation example 1and Operation example 2 of the driving device according to Embodiment 1of the present invention.

FIG. 7 is a time chart, upon fault occurrence, between an MCU and adriving device in Operation example 2 of the driving device according toEmbodiment 1 of the present invention.

FIG. 8 is an explanatory diagram illustrating a memory map pertaining tofault determination in the driving device according to Embodiment 1 ofthe present invention.

FIG. 9 is a time chart, upon fault occurrence, between an MCU and adriving device in Operation example 3 of the driving device according toEmbodiment 1 of the present invention.

FIG. 10 is an explanatory diagram illustrating an additional memory mappertaining to fault determination in the driving device according toEmbodiment 1 of the present invention.

FIG. 11 is a flowchart illustrating a process flow in Operation example3 of the driving device according to Embodiment 1 of the presentinvention.

FIG. 12 is a block diagram illustrating the structure of a variation ofthe driving device according to Embodiment 1 of the present invention.

FIG. 13 is a block diagram illustrating an example of a logic elementthat makes up a program logic array in a variation of the driving deviceaccording to Embodiment 1 of the present invention.

DESCRIPTION OF EMBODIMENTS

Embodiments for carrying out the present invention will be explainednext with reference to accompanying drawings.

A general power train ECU will be explained first in order to betterunderstand the embodiments of the present invention. FIG. 1 illustratesthe structure of a general power train ECU. The ECU 1 consists of amicro control unit (MCU) 2, as a control unit, a sensor interface 4 anda driving device 5. The ECU 1 is connected to a sensor (group) 3 and anactuator (group) 6. The sensor (group) 3 is one or more sensors fordetecting the state of a vehicle. The sensor (group) 3 includes, forinstance, at least one sensor from among an accelerator sensor, anairflow sensor, an intake air temperature sensor, a throttle openingsensor, a water temperature sensor, a rotation sensor, an O₂ sensor anda vehicle speed sensor. The actuator (group) 6 is one or more actuators.Examples of the actuators 6 include, for instance, a solenoid valve, aninjector, a throttle valve and an igniter.

The MCU 2 has control software 2 a therein. The MCU 2 receivesinformation from the sensor (group) 3 via a sensor interface 4. The MCU2 controls one or more actuators 6 via the driving device 5.

The driving device 5 drives the actuators 6 by means of control by theMCU 2. The driving device 5 has a fault detection device 11 installedtherein. The driving device 5 detects timely, using the fault detectiondevice 11, a fault (power short, ground short, open, overcurrent) in theactuators 6.

In order to check the occurrence or absence of a fault in the actuators6, the MCU 2 issues periodically an instruction to the driving device 5.Upon reception of the instruction, the driving device 5 transmits, tothe MCU 2, a fault report indicating the occurrence or absence of afault in the actuators 6. The MCU 2 monitors the state of the actuators6 by checking the fault report from the driving device 5.

FIG. 2 illustrates communication between the MCU 2 and the drivingdevice 5. Firstly, the MCU 2 issues a fault determination request(instruction) to the driving device 5. The driving device 5 determinesvarious types of fault (power short, ground short, open, overcurrent) inthe actuators 6, using the fault detection device 11, and transmits thedetermination result, as a fault report, to the MCU 2. If no fault hasoccurred in the actuators 6, the MCU 2 keeps on issuing a faultdetermination request to the driving device 5 over a presetdetermination period P1. Depending on the type of the actuator 6, theMCU 2 may in some instances transmit a fault determination request overa prescribed number of times, within a limit time, under a differentfault determination condition. The fault determination conditionincludes, for instance, the voltage or temperature of the actuator.

By contrast, when a fault occurs in at least one of the actuators 6,i.e. in a case where the determination result is NG, as illustrated inFIG. 3, the MCU 2 instructs an action Act based on analyzed faultcontent, to the driving device 5. As the action Act, the MCU 2 issues,to the driving device 5 that is controlling the actuator 6 in which afault has occurred, for instance an instruction for discontinuing theoperation of the actuator 6.

Ordinarily, a plurality of driving devices 5 is installed in the ECU 1.The MCU 2 monitors the fault state of each actuator 6 to be controlled.The MCU 2 triggers information from the sensor (group) 3, and processesin real time information having been worked in the sensor interface 4.The MCU 2 must perform, in real time, various tasks for processes otherthan the foregoing, and must exchange information with a communicationinterface. Accordingly, the ECU 1 requires a mechanism for reducing asmuch as possible communication load associated with the above faultdetermination.

The required specifications of the fault determination request depend oneach actuator 6. Accordingly, the driving device 5 preferably has ahighly versatile, reconfigurable fault determination function.Otherwise, it becomes necessary to re-design the driving device 5 foreach actuator 6. Higher costs and development delays may be incurred insuch a case.

In the communication between the MCU and the driving device, however,determination and control by the MCU are required only upon faultoccurrence (determination result NG). Vehicular devices have higherreliability than consumer products for household use, and hence theprobability of fault occurrence in such vehicular devices is very low.Therefore, if the fault determination requirement that is requested foreach driving device is satisfied, it is sufficient to report thenecessary information to the MCU, from each driving device, only uponfault occurrence. In the embodiment of the present invention, therefore,a fault determination device is provided, in each driving device, torecognized fault determination conditions. The driving device isprovided with a function of sending a fault report to the MCU,periodically or upon fault occurrence. As a result, communicationtraffic is alleviated while contributing to upholding real-timeprocessing. In the embodiment of the present invention, the drivingdevice is provided with a simple processor and a memory. The drivingdevice performs fault determination through software processing, using asimple processor and a memory. As a result, the driving device need notbe re-designed for actuators having a specific fault determinationrequirement.

Embodiments of the present invention will be explained next. The drivingdevice 5 according to Embodiment 1 of the present invention drives oneor more actuators 6 that are installed in a vehicle, and upon receptionon an instruction from the MCU 2, determines the occurrence or absenceof a fault in the actuators 6.

Embodiment 1

FIG. 4 illustrates the structure of the driving device according toEmbodiment 1 of the present invention. As illustrated in FIG. 4, thedriving device 5 according to Embodiment 1 is connected between the MCU2 and the actuators 6. The number of actuators 6 is one or more. Theseactuators 6 make up an actuator group.

Also, in Embodiment 1, the driving device 5 and the MCU 2 are installedin the ECU 1 together with the sensor interface 4 as illustrated inFIG. 1. The structure of the ECU 1 and the structure of the sensor(group) 3 are basically identical to those of FIG. 1, and an explanationthereof will be omitted herein. The difference between Embodiment 1 andFIG. 1 resides in the structure and operation of the driving device 5.

A serial interface 7, a logical unit 8, a fault detection device 11, andan interrupt generator 15 are provided in the driving device 5.

The serial interface 7 exchanges signals with the MCU 2. The serialinterface 7 receives instructions from the MCU 2 and transmits faultreports to the MCU 2.

One fault detection device 11 is provided for each actuator 6. Eachfault detection device 11 monitors faults (power short, ground short,open, overcurrent) in the respective actuator 6, and stores anormal/abnormal status, in the form of a fault flag, in a fault flagregister that is provided in a data unit 10 b of a memory device 10.Specifically, the fault flag is set to “0” in a case where the actuator6 is normal, and is set to “1” in a case where the actuator 6 isabnormal.

The logical unit 8 decodes the instructions from the serial interface 7,and executes a necessary process. The logical unit 8 transmits, to theserial interface 7, information that is necessary for reporting to theMCU 2. Further, a central processor unit CPU (CPU) 9, as a processor,the memory device 10, a timer device 16 and a counter device 17 areprovided in the logical unit 8.

The memory device 10 has a code unit 10 a in which programs are written,and the data unit 10 b in which data is written. Respective vectorshaving a fault determination requirement described therein are allocatedfor each fault detection device 11 in the code unit 10 a. Upon receptionof an instruction from the MCU 2, the driving device 5 executes, bymeans of each fault detection device 11, fault determination based onthe above fault determination requirement, using the CPU 9. The memorydevice 10 programs and stores, for each fault detection device 11corresponding to a respective actuator 6, a limit time T1, thedetermination period P1, and the number of repeats N, for performingfault determination, as well as a fault determination requirement.

The CPU 9 consists of a computing device 12, a control device 13 and aregister device 14. The CPU 9 defines and executes, by means of thecomputing device 12 and the control device 13, a program sequence thatis described in the vectors that are registered in the code unit 10 a ofthe memory device 10.

The interrupt generator 15 monitors fault flags that are stored in thedata unit 10 b of the memory device 10. The interrupt generator 15detects that a fault has occurred in the actuator (group) 6 in a casewhere a fault flag is “1”. When a fault occurs, the interrupt generator15 transmits an interrupt signal to the MCU 2.

The timer device 16 measures the limit time T1 and determination periodP1 described below.

The counter device 17 counts the number of repeats N over which thefault detection device 11 repeatedly performs fault determination, andthe number of fault occurrences in the respective actuator 6 as detectedthrough that fault determination.

The power source and clock for operating the above logic in the serialinterface 7, the logical unit 8, the fault detection device 11 and theinterrupt generator 15 in the driving device 5 are supplied from outsidethe driving device 5.

FIG. 12 illustrates the structure of another form (variation) of thedriving device according to Embodiment 1 of the present invention.

In the structure of FIG. 12, a program logic array 18 is provided,instead of the CPU 9, the timer device 16 and the counter device 17 ofthe structure of FIG. 4. In FIG. 12, hardware configuration informationbased on a fault determination request, from outside or from the MCU 2,is downloaded to the code unit 10 a of the memory device 10, via theserial interface 7. The program logic array 18 reconstructs a logic onthe basis of the information that is downloaded to the code unit 10 a.

The operation in Embodiment 1 will be explained next on the basis ofOperation examples 1 to 4. The operation in the case of the structure ofFIG. 4 will be explained in Operation examples 1 to 3, and the operationof the case of the structure of FIG. 12 will be explained in Operationexample 4.

Operation Example 1

The driving device 5 performs a routine work for determining theoccurrence or absence of a fault in a respective actuator 6, namely“receives a fault determination request from the MCU 2, and replies witha determination result to the MCU 2”. The driving device 5software-processes the routine work according to a program sequencestored in the code unit 10 a of the memory device 10, using the CPU 9.The driving device 5 generates an interrupt signal for the MCU 2, usingthe interrupt generator 15, only when a fault occurs in the actuator 6.In other words, if no fault has occurred in the actuator 6, the drivingdevice 5 puts together the determination result of every givendetermination period P1 for N times, and transmits the result in theform of a fault report R1 to the MCU 2 after a preset limit time T1 haselapsed. As a result, data communication between the MCU 2 and thedriving device 5 is significantly reduced, while upholding real-timeprocessing.

FIG. 5 illustrates a time chart during normal operation of the MCU 2 andthe driving device 5. In FIG. 5, the limit time T1 is a period of timeover which the driving device 5 performs fault determination. The limittime T1 is set beforehand. The number of repeats N is the number oftimes that the driving device 5 repeatedly performs fault determination.The number of repeats N is set beforehand. The determination period P1is a period during which the driving device 5 carries out faultdetermination. Instruction C1 is s fault determination request that istransmitted from the MCU 2 to the driving device 5. The faultdetermination request is an instruction of requesting the driving device5 to perform fault determination of determining whether or not a faulthas occurred in a respective actuator 6. Determination D1 denotes thefault determination carried out by the driving device 5. The report R1is the determination result that is transmitted by the driving device 5to the MCU 2. The limit time T1, the number of repeats N, and thedetermination period P1 may be set according an instruction from the MCU2 or from outside, or may be preset in the driving device 5.

In the limit time T1, firstly the MCU 2 transmits a fault determinationrequest (instruction C1) to the driving device 5, as illustrated in FIG.5. In response to the received instruction C1, the driving device 5repeatedly carries out fault determination for the number of repeats N,until the limit time T1 elapses. The period of repetition herein is thedetermination period P1. When the limit time T1 has elapsed, the drivingdevice 5 transmits the determination result (fault report R1) to the MCU2. The determination result (fault report R1) includes a faultdetermination result for the number of repeats N.

After the fault determination request (instruction C1) has been issuedby the MCU 2 to the driving device 5, thus, no communication takes placebetween the MCU 2 and driving device 5 until the limit time T1 elapses,as illustrated in FIG. 5. That is, no communication load arises betweenthe MCU 2 and the driving device 5 unless a fault occurs in the actuator(group) 6. In the general case illustrated in FIG. 2, by contrast,communication between the MCU 2 and the driving device 5 takes place ateach determination period P1. A comparison between FIG. 5 and FIG. 2reveals that communication load is thus significantly reduced inEmbodiment 1.

In Embodiment 1, the fault state of each actuator 6 can be monitoredperiodically by setting beforehand the number of repeats N. A comparisonbetween FIG. 5 and FIG. 2 reveals that in Embodiment 1, the drivingdevice 5 repeatedly carries out the fault determination D1, similarly toFIG. 2, even though there is no instruction from the MCU 2. Thedetermination result need not be transmitted to the MCU 2 at everydetermination period P1 if no fault occurs in any of the actuators 6. InEmbodiment 1, therefore, the driving device 5 transmits collectively tothe MCU 2 the determination results for N times, in the form of thefault report R1, when the limit time T1 has elapsed. Communication loadin Embodiment 1 is significantly reduced as a result.

In Embodiment 1, in a case where a fault occurs in at least one of theactuators 6, the driving device 5 immediately transmits an interruptsignal to the MCU 2 using the interrupt generator 15, to notify the MCU2 of the occurrence of the fault. As a result, the driving device 5 canimmediately notify the MCU 2 of the fault occurrence. Compared with theinstance of FIG. 3, fault determination and fault detection in theactuators 6 are not carried out herein until reception of a faultdetermination request (instruction C1) from the MCU 2 in FIG. 3, andhence the notification of a fault occurrence is delayed correspondingly.The maximum delay time is the length of time of the determination periodP1. In Embodiment 1, therefore, quick notification of fault occurrenceis achieved, and hence real-time processing is upheld.

In Embodiment 1, there are provided the CPU 9 and the memory device 10,and fault determination is set to be carried out through softwareprocessing. Accordingly, a fault determination requirement that isspecific of each actuator 6 based on various fault determinationrequests and scenarios can be modified through simple rewriting of thecontent of the code unit 10 a of the memory device 10. The various faultdetermination requirements of the actuators 6 can be met as a result inEmbodiment 1 using software, without modifying the hardware of thedriving device 5.

FIG. 6 illustrates a fault diagnosis flowchart of the driving device 5according to Operation example 1 of Embodiment 1.

In step S001, as illustrated in FIG. 6, the driving device 5 firstlyimports a programs and parameters from the MCU 2 into the memory device10 in the logical unit 8, via the serial interface 7.

Next, if there is a parameter for setting the limit time T1 in theprogram imported into the memory device 10, in step S002 the drivingdevice 5 sets the limit time T1 in the timer device 16 on the basis ofthe above parameter.

Next, if there is a parameter for setting the number of repeats N in theprogram imported into the memory device 10, in step S003 the drivingdevice 5 sets the number of repeats N in the counter device 17 on thebasis of the above parameter. The counter device 17 decrements thecounter value of the number of repeats each time that one faultdetermination is complete. The counter device 17 also resets the countervalue of the number of fault occurrences at that time. The counterdevice 17 increments the counter value of the number of faultoccurrences each time that a fault is detected as a result of faultdetermination.

Next, if there is a parameter for setting the determination period P1 inthe program that is imported into the memory device 10, in step S004 thedriving device 5 sets the determination period P1 in the timer device 16on the basis of the above parameter.

Next, if there is a specific fault determination condition for eachactuator 6, in step S005 the driving device 5 sets the specific faultdetermination condition in the memory device 10. On the other hand, ifthere is not a specific fault determination condition for each actuator6, the fault determination conditions (default values) stored beforehandin the memory device 10 are kept unchanged. The fault determinationcondition includes at least one from among, for instance, the voltage,temperature and operation mode of the actuator 6, or the ambienttemperature of the actuator 6.

Next, in step S006, the driving device 5 receives a fault determinationrequest (instruction C1) from the MCU 2, and in response thereto,performs fault determination of each actuator 6 using the faultdetection device 11, through control by the CPU 9. The fault detectiondevice 11 determines the occurrence or absence of a fault in eachactuator 6, and stores a normal/abnormal status, in the form of a faultflag “0”/“1”, in the fault flag register of the data unit 10 b of thememory device 10. Upon fault detection, the fault detection device 11also detects the type of the fault (power short, ground short, open,overcurrent), and the type of the fault is stored in a detailedinformation register of the data unit 10 b of the memory device 10.

Next, in step S007, the driving device 5 checks the content of the faultflag register of the data unit 10 b of the memory device 10 using theinterrupt generator 15. If there is no fault, the process proceedsaccordingly to step S008. The operation in a case where a fault hasoccurred will be explained in Operation example 2 described below.

In step S008, the driving device 5 stands by until a determination timedetermined according to the determination period P1 elapses, on thebasis of the time measured by the timer device 16, and once thedetermination time has elapsed, the process proceeds to step S009.Measurement of the determination time is initiated, as a starting point,at the point in time of reception of the fault determination request(instruction C1) from the MCU 2.

In step S009, the driving device 5 checks whether or not the limit timeT1 has elapsed, on the basis of the time measured by the timer device16. If the limit time T1 has elapsed, the process proceeds to step S102,and the driving device 5 sets an error flag in the data unit 10 b of thememory device 10, and outputs a fault report R1 to the MCU 2. On theother hand, if the limit time T1 has not elapsed, the process proceedsto step S010.

In step S010, the driving device 5 checks the repetition counter valueof the counter device 17; if the repetition counter value has beenreached the number of repeats N, the process proceeds to step S011,whereas if the repetition counter value has not been reached the numberof repeats N, the process returns to step S005, and the process fromstep S005 to S009 is repeated.

In step S011, the driving device 5 transmits the fault determinationresult to the MCU 2, via the serial interface 7. After the abovetransmission, the driving device 5 terminates the program process.

Similarly, also in step S012, the driving device 5 transmits the faultdetermination result to the MCU 2, via the serial interface 7. After theabove transmission, the driving device 5 terminates the program process.

Whenever the fault determination condition in the memory device 10 needsto be modified, the driving device 5 modifies the fault determinationcondition in step S005.

The process corresponding to a time of fault occurrence in step S007will be explained below in Operation example 2, with reference to FIG.7.

Operation Example 2

FIG. 7 illustrates a time chart in a case where a fault occurs in atleast one of the actuators 6. In FIG. 7, the reference symbol Int is aninterrupt signal that is transmitted from the interrupt generator 15. Inthe example of FIG. 7, the interrupt signal Int is at a H levelnormally, and at a L level abnormally. However, the level of theinterrupt signal Int is not limited thereto, and the interrupt signalInt may be set to be at a H level abnormally, and at a L level normally.In FIG. 7, the reference symbol C3 is a detailed information requestthat is transmitted from the MCU 2 to the driving device 5. The detailedinformation request is an instruction of requesting the driving device5, upon occurrence of a fault, to transmit the fault report R1 includingdetailed information relating to that fault. The reference symbol Act isan action corresponding to the fault that has occurred.

As illustrated in FIG. 7, in the routine work by the driving device 5illustrated in the flow of FIG. 6, in a case where in step S007 it isdetermined that a fault has occurred in one of the actuators 6, theinterrupt generator 15 transmits the interrupt signal Int to the MCU 2,to thereby notify the MCU 2 of the occurrence of the fault. The MCU 2outputs the detailed information request (instruction C3) to the drivingdevice 5 in order to obtain detailed information for the fault. Inresponse thereto, the driving device 5 transmits, to the MCU 2, thefault report R1 including the detailed information of the fault. On thebasis of the content of the received fault report R1, the MCU 2determines the content of the action that is to be instructed to thedriving device 5. As a processing example, for instance, the MCU 2instructs the driving device 5 to stop the periodic fault determinationroutine and stop immediately the actuator at which the fault hasoccurred. The determination method of the action content by the MCU 2may be, for instance, a method wherein the MCU 2 has a look-up table inwhich there is established beforehand a correspondence between thecontent of the fault report R1 and the content of the actioncorresponding thereto, and the MCU 2 refers to the look-up table todetermine the content of the action that is to be instructed to thedriving device 5.

FIG. 8 illustrates a memory map in the data unit 10 b of the memorydevice 10. As the top diagram in FIG. 8 illustrates, occurrence orabsence of a fault for each actuator 6 that is driven by the drivingdevice 5 is allocated to each bit in a fault flag register at a specificaddress (herein, 6′b000000). The values of these bits are fault flags. Afault flag “0” represents normal and “1” represents abnormal.Information indicating in which actuator (driver 0, 1, 2 or 3) a faulthas occurred, and fault type information indicating what type of faulthas occurred (overcurrent, open, power short, ground short), is storedas fault detailed information, as the bottom diagram in FIG. 8illustrates.

As described above, when a fault occurs in at least one actuator fromamong the actuators 6, a determination result by the fault detectiondevice 11 is written, as fault flags, in the fault flag register of thedata unit 10 b of the memory device 10 according to the memory mapillustrated in FIG. 8. The interrupt generator 15 checks the value ofeach fault flag in the fault flag register of the data unit 10 b of thememory device 10, and if the value of a fault flag is “1”, generates theinterrupt signal Int that is to be transmitted to the MCU 2.

Upon reception of the interrupt signal Int, the MCU 2 transmits a faultdetails request (C3) to the driving device 5. Upon reception of thefault details request (C3), the driving device 5 firstly refers to thefault flags of the fault flag register (6′b000000) and obtains faultinformation indicating in which actuator 6 (driver 0, 1, 2 or 3) thefault has occurred. Further, the driving device 5 refers to the faultdetailed information in the fault flag register (6′b000000) and obtainsfault detailed information, for instance fault type information(overcurrent, open, power short, ground short) for the actuator 6 inwhich a fault has occurred. The driving device 5 generates a faultreport R1 including the fault information and the fault detailedinformation, and transmits the fault report R1 to the MCU 2.

On the basis of the fault report R1, the MCU 2 can recognize, forinstance, the actuator 6 (driver 0, 1, 2 or 3) in which a fault hasoccurred, and the specific type of the fault (overcurrent, open, powershort, ground short). The MCU 2 analyzes the recognized fault content,and instructs an action Act based on the analyzed fault content, to thedriving device 5. As the action Act, the MCU 2 issues, to the drivingdevice 5 that is controlling the actuator 6 in which a fault hasoccurred, for instance an instruction for discontinuing the operation ofthat actuator 6.

In FIG. 7 an example is explained where the MCU 2 transmits the faultdetails request (C3) in a case where an interrupt signal is received,but Embodiment 1 is not limited to this scheme. For instance, thefollowing scheme may be resorted to as well.

Firstly, the MCU 2 recognizes fault occurrence, through reception of theinterrupt signal Int. The MCU 2 transmits first, to the driving device5, the fault determination request (instruction C1) in order to obtaininformation relating to the fault. In response thereto, the drivingdevice 5 refers to the fault flags of the fault flag register(6′b000000), and transmits, to the MCU 2, a fault report R1 includingfault information. On the basis of the fault report R1, the MCU 2 canrecognize in which actuator 6 (driver 0, 1, 2 or 3) a fault hasoccurred.

Next, the MCU 2 transmits a fault details request (C3) to the drivingdevice 5, in order to obtain detailed fault type information(overcurrent, open, power short, ground short) for the actuator 6 inwhich a fault has occurred. In response thereto, the driving device 5refers to the fault detailed information in the fault flag register(6′b000000), and transmits, to the MCU 2, the fault report R1 includingthe fault detailed information.

Also, fault information and fault detailed information may be obtainedin two stages, i.e. transmission of the fault determination request(instruction C1) and reception of the fault report R1 in responsethereto, and, thereafter, transmission of the fault details request(C3).

FIG. 6 serves also as a fault detection flowchart of Operation example2. In Operation example 2 the process from step S001 to S006 isidentical to that in Operation example 1. Accordingly, the explanationwill omit step S001 to S006 and will apply to step S007 onwards. InOperation example 2, a fault occurs in an actuator 6; in step S007,accordingly, the process proceeds to step S012. In step S012, thedriving device 5 sets an error flag in the data unit 10 b of the memorydevice 10. Simultaneously therewith, the driving device 5 transmits theinterrupt signal Int to the MCU 2 using the interrupt generator 15, andimmediately notifies the MCU 2 of the fault occurrence. After the abovenotification, the driving device 5 terminates the program process.

In a case where a fault occurs in step S007 in the example of theflowchart of FIG. 6, the process proceeds to step S012 and exits theloop. However, the process may remain in the loop, and the faultdetermination result may be reported to the MCU 2 from the drivingdevice 5 after the number of repeats has been reached, as in Operationexample 1. Such modification and changeover of process contents can becontrolled according to a program sequence that is loaded onto the codeunit 10 a of the memory device 10.

Operation Example 3

An example will be explained herein in which, unlike in the case ofOperation example 2, even though a fault occurs, fault determination iscarried out for the number of times set in the number of repeats N, asillustrated in FIG. 9, without transmission of the interrupt signal Intimmediately following detection of a fault; thereafter, the interruptsignal Int is transmitted according to a comparison between the numberof fault occurrences and a prescribed number of errors (threshold value)set beforehand. In Operation example 3, specifically, fault detection isrepeatedly carried out for the number of repeats N, over thedetermination period P1 within the limit time T1, and the interruptsignal Int is transmitted to the MCU 2 in a case where, as a result, thenumber of fault occurrences is equal to or greater than a prescribednumber of errors determined beforehand (threshold value).

In fault determination in Operation example 3, a fault is not determinedimmediately upon occurrence of an error once, unlike in the case ofOperation example 1 and Operation example 2. In Operation example 3, forinstance, the interrupt signal Int for the MCU 2 is generated throughexecution of fault determination on the basis of a fault determinationresult (number of error occurrences equal to or greater than aprescribed number of errors (threshold value)) after execution of faultdetermination for the number of repeats N, without causing the interruptsignal Int to be generated in the MCU 2 immediately unlike in the caseof Operation example 2. To that end, a fault mask register such as theone FIG. 10 is provided for each actuator 6, similarly to the case offault flags of FIG. 8. In the fault mask register, a fault mask of anactuator 6 for which an interrupt to the MCU 2 is generated immediatelyupon occurrence of a fault is set to “1”, and the fault mask of anactuator 6 for which no interrupt to the MCU 2 is generated immediately,even if a fault occurs, is set to “0”. The memory device 10 has thus afault mask register for designating, for each actuator 6, an alternativebetween permitting and prohibiting transmission of the interrupt signalInt by the interrupt generator 15. As a result, the interrupt generator15 does not transmit the interrupt signal Int to the MCU 2 for theactuators 6 the fault mask whereof has been set to “0”, even if thefault flag is “1”. In a case where, by contrast, the fault flag is “1”,the interrupt generator 15 immediately transmits the interrupt signalInt to the MCU 2, for the actuators 6 the fault mask whereof has beenset to “1”. For the actuators 6 the fault mask whereof has been set to“0”, thus, software processing is performed wherein the interrupt ismasked, and upon fault determination after execution of faultdetermination for the number of repeats N, the mask is cleared, toreflect thereby the fault determination result on an error flag.

FIG. 11 illustrates a fault diagnosis flowchart of the driving device 5according to Operation example 1 of Embodiment 3. The process in stepsS101 to S104, S107 to S108, S111 to S113 and S116 of FIG. 11 correspondbasically to steps S001 to S006 and S008 to S011 in FIG. 6. Accordingly,these processes will be explained next in a simplified manner.

As illustrated in FIG. 11, the driving device 5 firstly imports programsand parameters from the MCU 2 into the memory device 10 in the logicalunit 8, via the serial interface 7, in step S101.

Next, if there is a parameter for setting the limit time T1 in theimported program, in step S102 the driving device 5 sets the limit timeT1 in the timer device 16 on the basis of the above parameter.

Next, if there is a parameter for setting the number of repeats N in theimported program, in step S103 the driving device 5 sets the number ofrepeats N in the counter device 17. The counter device 17 decrements thecounter value each time that one fault determination is complete.

Next, if there is a parameter for setting the determination period P1 inthe imported program, in step S104 the driving device 5 sets thedetermination period P1 in the timer device 16, on the basis of theabove parameter.

Next, in step S105, the prescribed number of errors (threshold value) isimported into the memory device 10, and the counter value of the numberof fault occurrences of the counter device 17 is reset.

Next, in step S106, interrupt mask information is allocated to the dataunit 10 b of the memory device 10 according to the memory map in FIG.10, in response to an instruction from the MCU 2 or from outside. Forthe sake of a simpler explanation, the fault mask is set herein to “0”for all the actuators 6.

Next, in step S107, a fault determination condition (voltage,temperature, operation mode and the like) is set, if there is any.

Next, in step S108, fault determination is performed in the faultdetection device 11. The fault detection device 11 determines theoccurrence or absence of a fault (power short, ground short, open,overcurrent) in each actuator 6, and stores a normal/abnormal status, inthe form of a fault flag “0”/“1”, in the fault flag register of the dataunit 10 b of the memory device 10. Upon fault detection, the faultdetection device 11 detects as well the type of the fault (power short,ground short, open, overcurrent), and the type of the fault is stored ina detailed information register of the data unit 10 b of the memorydevice 10.

Next, in step S109, the driving device 5 checks the value of the faultflags in the fault flag register in the data unit 10 b of the memorydevice 10 having the fault determination result stored therein, usingthe interrupt generator 15. If a fault has occurred, the processproceeds to step S110; otherwise, the process skips S110.

In step S110 the counter value of the number of fault occurrences of thecounter device 17 is incremented. In this case, “0” is set as the faultmask in the fault mask register, and, accordingly, no interrupt signalto the MCU 2 is generated by the interrupt generator 15.

In step S111 the process waits out until the determination period P1elapses.

Next, in step S112, it is checked where the limit time T1 has beenexceeded or not. If the limit time T1 has been exceeded, this isreported to the MCU 2, and the present process is terminated. If thelimit time T1 has not been exceeded, the process proceeds to step S113.

In step S113 there is checked the counter value of the number of repeatsN of the counter device 17; if the number of repeats N has not beenreached, the process from step S107 to S112 is repeated. If the faultdetermination condition needs to be modified, the latter is modified instep S107. If on the other hand the number of repeats N has beenreached, the process proceeds to step S114.

In step S114 the value of the fault mask in the fault mask register isset to “1”.

In step S115, the prescribed number of errors (threshold value) and thecounter value of the number of fault occurrences of the counter device17 are compared; if the counter value of the number of fault occurrencesexceeds the prescribed number of errors (threshold value), the drivingdevice 5 raises an error flag. In that case, the fault mask register iscleared to “1”, and an interrupt signal Int to the MCU 2 is generated bythe interrupt generator 15.

In step S116, the driving device 5 transmits the fault determinationresult to the MCU 2, via the serial interface 7. After the abovetransmission, the driving device 5 terminates the program process.

Pseudo-errors can be reduced thus in Operation example 3 since thedriving device 5 has a function of masking interrupts.

Operation Example 4

Operation examples 1, 2 and 3 above have been described for the hardwarestructure illustrated in FIG. 4. In these operation examples, theprogram in the code unit 10 a of the memory device 10 is read andsequentially processed by the CPU 9. In a case where processing at ahigher speed is required, such processing needs to be implemented in theform of hardware. In Operation example 4 an example will be illustratedin which the same functions as in Operation examples 1, 2 and 3 arerealized on the basis of a different hardware structure. In Operationexample 4 there will be explained an operation example for the hardwarestructure illustrated in FIG. 12.

In FIG. 12, a program logic array 18 substitutes for the CPU 9 havingthe computing device 12, the control device 13 and the register device14, as well as for the timer device 16 and the counter device 17, ofFIG. 4. The program logic array is for instance a circuit configuredfrom a logic element (group) 21 each made up of a look-up table 22having three inputs and one output, and a register 23 as illustrated inFIG. 13, such that an arbitrary logic can be constructed throughre-configuration of the wiring of the logic elements 21 that are laidout according to the below-described configuration.

The program sequence described in FIG. 6 or FIG. 11 is mapped in aformat referred to as configuration information, using a logic synthesistool. The configuration information is stored in the memory device 10,from outside or from the MCU 2, via the serial interface 7, to enable asa result hardware processing of the above functions.

The process flow and process content in Operation example 4 arebasically identical to those of Operation examples 1 to 3, and anexplanation thereof will be omitted herein. The particulars of theprocess flow and process content are to be referred thus to those ofOperation examples 1 to 3. When referring to Operation examples 1 to 3,however, all the operations of the CPU 9 having the computing device 12,the control device 13 and the register device 14, and of the timerdevice 16 and the counter device 17 are to be re-read as the operationof the program logic array 18.

In Operation example 4, thus, the CPU 9, the timer device 16 and thecounter device 17 in Operation examples 1 to 3 are configured in theform of the program logic array 18, and hence the same operations as inOperation examples 1 to 3 are enabled herein. In Operation example 4 aswell, therefore, the fault determination requirement can be modified foreach actuator 6, as is the case in Operation examples 1 to 3. The sameeffects as those of Operation examples 1 to 3 can be elicited as aresult in Operation example 4.

As explained above, using Operation examples 1 to 4, Embodiment 1 of thepresent invention allows performing fault determination according to adesired fault determination requirement, simply through rewriting of thefault determination requirement in the memory device 10, since thedriving device determines faults through software processing. As aresult, fault determination requirements that are specific to eachactuator 6 based on various fault determination requests and scenarioscan be used for diverse specifications of fault determination, withoutmodifying the driving device 5. This can be expected to translate intoshorter product development lead times and lower costs, while allowingfor an implementation in the form of an application specific standardproduct (ASSP) that includes the driving device 5.

The fault determination results for N times are set to be transmittedcollectively, without transmission of a determination result each timethat fault determination is performed. Accordingly, this contributessignificantly to reducing data traffic volume between the MCU 2 and thedriving device 5 and to uphold real-time processing. Moreover, a powerconsumption reduction effect and noise reduction effect can be expectedto be achieved through a reduction in the volume of data traffic.

Further, there is provided a fault mask register for designating whetheran interrupt is to be masked or not, and the interrupt signal Int is setto be transmitted only in a case where fault occurrence is detected fora predetermined or greater number of times, without transmission of aninterrupt signal immediately after fault detection. Therefore, thisallows eliminating pseudo-fault determination from the driving device 5to the MCU 2, while reducing processing in the MCU 2.

As illustrated in FIG. 12, there may be used a configuration-basedprogram logic array 18, in which case processing performance can be madefaster while maintaining the above effects.

What is claimed is:
 1. A driving device that is connected between acontrol unit and an actuator and that drives the actuator throughcontrol by the controller, the driving device comprising: a faultdetection device that performs one or more fault determinations todetermine whether or not a fault occurs in the actuator; a serialinterface that communicates with the controller; a memory device thatstores a result of the fault determinations and a program executed by aprocessor via the serial interface; the processor that, according to afault determination request from the controller, executes the program,and causes the fault detection device to execute the faultdeterminations; a timer that measures a time limit time for the faultdeterminations and a determination period for each of the faultdeterminations; and a counter that counts, during the time limit, anumber of times that the fault determinations are executed by the faultdetection device, and a number of fault occurrences in the actuator thatare detected by the fault detection device, wherein, in response toreceiving the fault determination request from the controller, theprocessor executes the program to cause the fault detection device toexecute the fault determinations for the number of times within the timelimit and to execute each of the fault determination during thedetermination period, and after the time limit elapses, transmits theresult of the fault determinations to the controller.
 2. The drivingdevice according to claim 1, wherein the memory device stores a faultdetermination requirement of the fault determinations for each faultdetection device corresponding to the actuator.
 3. The driving deviceaccording to claim 2, wherein the memory device stores the time limit,the determination period, the number of times that the faultdeterminations are executed and the fault determination requirement, foreach fault detection device corresponding to the actuator.
 4. Thedriving device according to claim 3, further comprising an interruptgenerator that detects the fault occurrences in the actuator based onthe result of the fault determinations stored in the memory device, andin a case where a fault has occurred in the actuator, transmits aninterrupt signal to the controller to notify the controller of the faultof the actuator.
 5. The driving device according to claim 4, wherein thememory device has a fault mask register for designating, for eachactuator, an alternative between permitting and prohibiting transmissionof the interrupt signal by the interrupt generator.
 6. The drivingdevice according to claim 2, further comprising an interrupt generatorthat detects the fault occurrences in the actuator based on the resultof the fault determinations stored in the memory device, and in a casewhere a fault has occurred in the actuator, transmits an interruptsignal to the controller to notify the controller of the fault of theactuator.
 7. The driving device according to claim 6, wherein the memorydevice has a fault mask register for designating, for each actuator, analternative between permitting and prohibiting transmission of theinterrupt signal by the interrupt generator.
 8. The driving deviceaccording to claim 1, wherein the processor, the timer and the counterare configured in a program logic array.
 9. The driving device accordingto claim 8, further comprising an interrupt generator that detects thefault occurrences in the actuator based on the result of the faultdeterminations stored in the memory device, and in a case where a faulthas occurred in the actuator, transmits an interrupt signal to thecontroller to notify the controller of the fault of the actuator. 10.The driving device according to claim 9, wherein the memory device has afault mask register for designating, for each actuator, an alternativebetween permitting and prohibiting transmission of the interrupt signalby the interrupt generator.
 11. The driving device according to claim 1,further comprising an interrupt generator that detects the faultoccurrence in the actuator based on the result of the faultdeterminations stored in the memory device, and in a case where a faulthas occurred in the actuator, transmits an interrupt signal to thecontroller to notify the controller of the fault of the actuator. 12.The driving device according to claim 11, wherein the memory device hasa fault mask register for designating, for each actuator, an alternativebetween permitting and prohibiting transmission of the interrupt signalby the interrupt generator.